Configuring and Controlling the Network
Sections in this topic:
Opening this Page in the Control Panel
To open this page in the Control Panel:
- In the Start menu, navigate to RTX64 4.5 Runtime and click RTX64 Control Panel.
- Click Configure and control the network.
About the Real-Time Network
The RTX64 real-time network consists of two primary components:
- Network Abstraction Layer (NAL) – a network layer that abstracts the network hardware and driver functions from the upper-level protocol stacks and provides management interfaces for those upper layers to easily query for and use available network assets. It is a separate protocol layer from the TCP/IP Stack. Using the NAL, you can more easily take advantage of network functionality such as EtherCAT, TSN (Time Sensitive Networks), and PTP (Precision Time Protocol). See RTX64 Network Abstraction Layer (NAL) for more information.
- TCP/IP Stack – a separate purchasable protocol stack that sits above the NAL and provides deterministic processing and networking capability. See Real-Time TCP/IP Stack for more information.
NOTE: The TCP/IP options will not be available if the TCP/IP component is not activated. For information on activating RTX64 components, see RTX64 Activation.
Running the Network in Verbose Mode
The RTX64 network supports a verbose mode that provides status information at key points during startup/shutdown and while running. This information will impact performance but is a useful way to trace what is happening during development or when debugging an issue.
To run the network in Verbose mode:
- Check the Run in verbose mode check box to enable verbose logging. Uncheck this box to disable verbose mode logging.
NOTE: Running the network in verbose mode may cause affect network performance during system shutdown.
- Restart the NAL for your changes to take effect. If you plan to make other changes that require a restart of the network, make those additional changes first and then restart the NAL when you are finished. You must stop all network-enabled processes before you can restart.
Configuring and Controlling the Network Abstraction Layer (NAL)
Manually Starting and Stopping the NAL
Use the start/stop controls to manually Start, Stop, or Restart the NAL. The status of the NAL appears to the left of the controls.
NOTE: The TCP/IP Stack depends on the NAL. Stopping the NAL will also stop the Stack.
Controlling NAL Startup Behavior
The status of the Start with the Subsystem check box determines whether the NAL starts automatically when the Subsystem starts.
To start the NAl with the Subsystem:
Select the Start with the Subsystem check box to start the NAL automatically when the Subsystem starts. This is the default behavior.
To Start the NAL independent of the Subsystem:
Clear selection of the Start with the Subsystem check box to prohibit the NAL from starting with the Subsystem.
NAL Configuration Settings
| Setting | Description | Action |
|---|---|---|
|
Set the processor on which the NAL runs |
Specifies the processor number on which the Network Abstraction Layer will run. NOTE: Processor numbers are zero based. By default, the first RTSS processor is the ideal processor. |
Choose a processor number from the drop-down list. |
NOTE: You must restart the network for your changes to take effect. If you plan to make other changes that require a restart of the network, make those additional changes first and then restart the network when you are finished. You must stop all network-enabled processes before you can restart.
Configuring and Controlling the TCP/IP Stack
NOTE: These settings require a valid RT-TCP/IP Stack license.
Manually Starting and Stopping the TCP/IP Stack
Use the start/stop controls to manually Start, Stop, or Restart the TCP/IP Stack. The status of the TCP/IP Stack appears to the left of the controls.
Controlling TCP/IP Stack Startup Behavior
The status of the Start with the NAL check box determines whether the TCP/IP Stack starts automatically when the NAL starts.
To start the TCP/IP STack with the NAL:
Select the Start with the NAL check box to start the TCP/IP Stack automatically with the NAL when the NAL is configured to start with the Subsystem (see above). This is the default behavior.
To Start the TCP/IP Stack independent of the NAL:
Clear selection of the Start with the NAL check box to not start the TCP/IP Stack with the NAL. Note that the NAL must be running before you can start the TCP/IP Stack.
TCP/IP Stack Configuration Settings
| Setting | Description | Action |
|---|---|---|
|
Set the processor on which the Stack runs |
The processor number on which the TCP/IP Stack will run. NOTE: Processor numbers are zero based. By default, the first RTSS processor is the ideal processor. |
Choose a processor number from the drop-down list. |
| Set the Stack timer processor |
The processor number of the Stack timer. NOTE: Processor numbers are zero based. By default, the first RTSS processor is the ideal processor. |
Choose a processor number from the drop-down list. |
| Set the Stack timer priority | The priority of the RT-TCP/IP Stack's first real-time timer thread, which updates timer variables. |
Enter a value in the text box. This value must be in the range 1-127, where 1 is the lowest priority and 127 is the highest priority. The default priority is 66. |
| Set the Stack timer execute priority | The priority of the RT-TCP/IP Stack's second real-time timer thread, which executes functions for expired timers. |
Enter a value in the text box. This value must be in the range 1-127, where 1 is the lowest priority and 127 is the highest priority. This value must be less than or equal to the value set for Stack timer priority. The default priority is 60. |
| Set the Stack timer interval |
The Stack timer is an internal timer that is used for all internal synchronization. The RT-TCP/IP Stack requires a fixed time notification for every Stack Timer Interval to update its elapsed time counters that are used within. Since there are several protocols implemented within the Stack, dealing with individual timers would be cumbersome. Hence, the RT-TCP/IP Stack is optimized to use a single notification for how much time is elapsed. The Stack timer system manages all of the different timers used within the RT-TCP/IP Stack. NOTE: Setting the Stack Timer Interval to a lower value results in closely spaced interrupts and can adversely impact the performance of the system. NOTE: This value must be a multiple of the HAL timer period. |
Enter a positive integer value (in milliseconds) in the text box. The specified value must be within the range of 1 to 1000 milliseconds. The default value is 100 milliseconds. |
| Set the IP reassembly timeout |
The time-out interval on IP reassembly. NOTE: We recommend that you decrease the IP reassembly time-out value so that it is less than the wrap-around time in an IP ID field. |
Enter a positive integer value in the text box. The default value is 60. The maximum value is 120. |
| Set the minimum number of ARP entries |
The maximum number of ARP entries allowed by the TCP/IP Stack. Each ARP cache entry is 100 bytes. It is recommended that the maximum ARP cache entries supported be greater than the total number of devices with which the interface communicates. NOTE: If the value is too small, the ARP cache can overflow. The potential for an overflow increases when the majority of network devices are offline. NOTE: When an overflow occurs, the TCP/IP Stack presents the warning message tfRtClone: ARP cache full, which indicates that the maximum number of entries supported should be increased. |
Enter a value in the text box. The default value is 256. |
| Set the maximum number of sockets |
The TCP/IP Stack allocates actual socket memory when it creates a socket, so it must know the maximum number of sockets it must create. |
Enter a value in the text box. The specified value must be in the range of 1 to The default value is 64. NOTE: In the running system, the socket range is 0 to the maximum number of sockets. For example, if the maximum number of sockets is set to 64, the range is 0 to 63. |
| Set the maximum concurrency |
The number of threads that are allowed to run concurrently within the TCP/IP Stack. The TCP/IP Stack needs to initialize certain attributes on when started to allow a certain number of threads to run and provide services for each client that requests services from the TCP/IP stack. For example, running a client and a server application will require 1 concurrency each. The TCP/IP Stack running by itself requires 1 concurrency to run the Loopback service. Loading and managing interfaces requires an average of 3 threads, thus a concurrency of 3 for each interface. NOTE: We recommend that this value be calculated automatically (default). NOTE: If the TCP/IP Stack requires more threads than the initialization process prepared for, the Stack will crash. |
Click the radio button that corresponds with the desired behavior:
If this value is non-zero during semaphore initialization, semaphores will be calculated as follows.
The system calculates the minimum value and then uses the greater of these values:
If User Value is lower, and if Verbose Mode is enabled, the following message will be generated:
The number of semaphores given by the current configuration (%d) is too low and should be increased. Initializing %d semaphores instead\n NOTE: Increasing this number may require a change to the maximum number of sockets. The Historical Maximum value represents the historical maximum Stack semaphore usage. When No historical data is displayed, it indicates there is not enough information to calculate a maximum. |
| Manage memory usage | Opens the Change memory allocation behavior page, where you can specify the amount of memory allocated to the TCP/IP Stack. |
NOTE: You must restart the TCP/IP Stack for your changes to take effect. If you plan to make other changes that require a restart of the network, make those additional changes first and then restart the TCP/IP Stack when you are finished.
